\section{2. SOLID 2: OCP, LSP og DIP}

\begin{center}
\line(1,0){500}
\end{center}

\begin{itemize}
\item Redegør for Open-Closed Principle, Liskov’s Substitution Principle (LSP) og Dependency Inversion Principle (DIP)
\item Redegør for, hvordan du mener anvendelsen af principperne fremmer godt SW design 
\item Vis et eksempel på anvendelsen af et eller flere af principperne i SW design. 
\item Redegør for konsekvenserne ved anvendelsen af OCP, LSP og/eller DIP – har det nogle ulemper?
\end{itemize}
\begin{center}
\line(1,0){500}
\end{center}

\subsubsection{OCP, LSP, DIP}
\textbf{Open-Closed Principle}
\begin{itemize}
    \item En klasse skal være åben for udvidelse men lukket for modifikation
    \item Hjælper med at gøre software klasser klar til udvidelse/ændring senere, uden at der skal ændres i den eksisterende implementation
    \item Klassen skal være åben for udvidelse (Open)
    \item Der skal ikke ændres i den eksisterende implementation (Closed)
\end{itemize}
\textbf{Liskov's Substitution Principle}
\begin{itemize}
    \item Den afledte klasse S af basis typen T skal overholde de egenskaber T implementerer
    \item Klienter der benytter sig af objekter af typen S vil se resultatet som var de er typen T
    \item Hvis programmet ikke ændrer funktionalitet ved at erstatte T med S er LSP overholdt
    \item Svagerer/samme pre-condition
    \item Stærkere/samme post-condition
    \begin{itemize}
        \item Et objekt af typen T kan erstattes af et objekt af den afledte type S uden at de ønskede egenskaber af programmet ændres
    \end{itemize}
    \item Typisk eksempel: Circle er afledt fra Ellipse, circle implementerer en set-metoder der gør at x og y akserne altid er ens
    \begin{itemize}
        \item Svagere post-condition
        \item Ikke noget problem hvis der er tale om "immutable" klasser
    \end{itemize}
\end{itemize}
\textbf{Dependency Inversion Principle}
\begin{itemize}
    \item Et høj-niveau modul skal ikke være afhængig af et lav-niveau modul, og omvendt, men abstraktioner
\begin{itemize}
        \item Et høj-niveau modul kender ikke til detajler i lav-niveau (HW, kommunikation etc)
        \item Lav-niveau kender ikke til det højere niveau (business logic, policies etc)
    \end{itemize}
    \item Abstraktioner skal ikke være afhængig af detajler, men detaljer skal være afhængig af abstraktioner
	\item Abstraktioner(interfaces) mellem lag
\end{itemize}
\subsubsection{Godt SW Design}
\begin{itemize}
    \item Alle SOLID-principperne understøtter hinanden
    \begin{itemize}
        \item Overholdes LSP vil udvidelse være nemmere - Åben for udvidelse
        \item Overholdes DIP vil der kunne ske ændringer i f.eks. driver-lag, uden der skal ændres i den eksisterende implementation - Lukket for modifikation
        \item Øger testability 
    \end{itemize}
\end{itemize}
\subsubsection{Eksempel}
\includegraphics[scale=0.22]{2-eksempel-OCP}
\begin{center}
\includegraphics[scale=0.22]{2-eksempel-LSP}
\end{center}

\subsubsection{Konsekvenser - Ulemper}
\begin{itemize}
    \item Det er muligt at der bliver introduceret overhead i form af for mange lag
    \item Skal være i baghovedet og ikke bruges som bibel
\end{itemize}